ETSITS101 498-3 V2.1.1 



(2005-10) 



Technical Specification 



Digital Audio Broadcasting (DAB); 

Broadcast website; 
Part 3: TopNews basic profile specification 



European Broadcasting Union 



/ 




Union Europeenne de Radio-Television 



EBU-UER 




WBIiSMiJib'flR, ', wSBy 




ETSI TS 101 498-3 V2.1.1 (2005-10) 



Reference 



DTS/JTC-DAB-41 
Keywords 



audio, broadcasting, DAB, digital, receiver 



ETSI 

650 Route des Lucioles 
F-06921 Sophia Antipolis Cedex - FRANCE 

Tel. : +33 4 92 94 42 00 Fax: +33 4 93 65 47 1 6 

Siret N ° 348 623 562 0001 7 - NAF 742 C 
Association a but non lucratif enregistree a la 
Sous-Prefecture de Grasse (06) N° 7803/88 



Important notice 



Individual copies of the present document can be downloaded from: 
http://www.etsi.org 

The present document may be made available in more than one electronic version or in print. In any case of existing or 

perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). 

In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive 

within ETSI Secretariat. 

Users of the present document should be aware that the document may be subject to revision or change of status. 

Information on the current status of this and other ETSI documents is available at 

http://portal.etsi.org/tb/status/status.asp 

If you find errors in the present document, please send your comment to one of the following services: 

http://portal.etsi.org/chaircor/ETSI support.asp 

Copyright Notification 

No part may be reproduced except as authorized by written permission. 
The copyright and the foregoing restriction extend to reproduction in all media. 

© European Telecommunications Standards Institute 2005. 

© European Broadcasting Union 2005. 

All rights reserved. 

DECT™, PLUGTESTS™ and UMTS™ are Trade Marks of ETSI registered for the benefit of its Members. 
TIPHON™ and the TIPHON logo are Trade Marks currently being registered by ETSI for the benefit of its Members. 
3GPP™ is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. 



ETSI 



ETSI TS 101 498-3 V2.1.1 (2005-10) 



Contents 



Intellectual Property Rights 4 

Foreword 4 

Introduction 4 

1 Scope 6 

2 References 6 

3 Abbreviations 7 

4 Syntax specification 7 

5 TopNews basic profile specification 7 

5.1 Introduction 7 

5.2 The TopNews MOT carousel 8 

5.3 MOT parameters for individual objects 8 

5.3.1 MOT Header Core settings 9 

5.3.2 The ProfileSubset parameter 9 

5.3.3 The ContentName parameter 9 

5.3.3.1 The ContentName parameter for interoperability 9 

5.3.4 The UniqueBody Version parameter 10 

5.3.5 The ContentSorting parameter 10 

5.3.5.1 TopNews Object type 11 

5.3.5.2 Presentation order of categories 11 

5.3.5.3 Presentation order of message objects 11 

5.3.5.4 Message objects in multiple categories 11 

5.3.6 The ContentDescription parameter 12 

5.3.7 The Headline parameter 12 

5.3.8 The Duration parameter 12 

5.3.9 The PresentationThreshold parameter, individual 13 

5.4 MOT parameters for the entire carousel 13 

5.4.1 The SortedHeaderlnformation parameter 13 

5.4.2 The SpecialEntry parameter 14 

5.4.3 The PresentationThreshold parameter, entire 14 

5.5 Other MOT parameters 15 

5.6 Application Signalling 15 

6 TopNews Application Structure 15 

6.1 Supported content types 15 

6.1.1 Content type audio 15 

6.1.1.1 MP2 parameters 15 

6.1.1.2 MP3 parameters 16 

6.2 Meta data for enhanced interoperability 16 

6.2.1 ID3tags 16 

6.2.2 Playlists / application meta data 16 

6.3 Category structure and signalling 17 

6.4 Object life cycle 18 

6.5 Navigation controls 18 

6.5.1 Change category 18 

6.5.2 Change message 19 

6.6 Quality of Service parameters 19 

6.6.1 Transport channel limitations 19 

6.6.2 Maximum object size 19 

6.6.3 Minimum receiver cache size 19 

6.6.4 Minimum receiver audio characteristics 19 

6.6.5 Minimum receiver display characteristics 19 

6.6.6 Maximum carousel period 20 

History 21 



ETSI 



ETSI TS 101 498-3 V2.1.1 (2005-10) 



Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by Joint Technical Committee (JTC) Broadcast of the European 
Broadcasting Union (EBU), Comite Europeen de Normalisation ELECtrotechnique (CENELEC) and the European 
Telecommunications Standards Institute (ETSI). 

NOTE 1: The EBU/ETSI JTC Broadcast was established in 1990 to co-ordinate the drafting of standards in the 
specific field of broadcasting and related fields. Since 1995 the JTC Broadcast became a tripartite body 
by including in the Memorandum of Understanding also CENELEC, which is responsible for the 
standardization of radio and television receivers. The EBU is a professional association of broadcasting 
organizations whose work includes the co-ordination of its members' activities in the technical, legal, 
programme-making and programme-exchange domains. The EBU has active members in about 60 
countries in the European broadcasting area; its headquarters is in Geneva. 

European Broadcasting Union 

CH-1218 GRAND SACONNEX (Geneva) 

Switzerland 

Tel: +41 22 717 21 11 

Fax: +4122 717 24 81 

The Eureka Project 147 was established in 1987, with funding from the European Commission, to develop a system for 
the broadcasting of audio and data to fixed, portable or mobile receivers. Their work resulted in the publication of 
European Standard, EN 300 401 [1], for DAB (see note 2) which now has worldwide acceptance. The members of the 
Eureka Project 147 are drawn from broadcasting organizations and telecommunication providers together with 
companies from the professional and consumer electronics industry. 

NOTE 2: DAB is a registered trademark owned by one of the Eureka Project 147 partners. 

The present document is part 3 of a multi-part deliverable. Full details of the entire series can be found in part 1 [4]. 



Introduction 



The growth of the Internet and the popularity of compressed audio in MP3 format makes audio based information 
services an extremely attractive way of providing information to users. Additionally audio data services are of huge 
interest in particular for in-car applications. 

MP2 and MP3 compression is the de facto standard on the Internet. This format is widely used and well supported for 
distribution of audio files and TopNews is a service that takes advantage of this development. The public has already 
accepted this technology that is now common both in the home and in the workplace. New types of devices have been 
created to accommodate for the popularity MP3 has reached: 

• Portable devices based on CD, MMC or other types of storage media. 

• Home receivers, that can handle MP3 from CD or hard disk. 

• Car stereos, capable of playing MP3 from CD-ROM. 
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TopNews gives DAB multiplex operators and service providers the opportunity to use for instance MP2 or MP3 as 
compressed audio content format. This supports information services by using the concept of a file or object download 
to the receiver that provides storage capacity for those objects (push and store). The application range for DAB value 
added services is dramatically enhanced with TopNews and this type of service is only feasible with a digital broadcast 
system. 

TopNews is designed to allow an entire bouquet of information to be delivered to a receiver using the broadcast channel 
of DAB. The information, like news or sport messages, is prepared as compressed audio objects by the service provider. 
These message objects are transmitted and then stored inside the receiver. The objects are sorted by freely definable 
categories. Index objects support the navigation within this collection of message objects. A category index is played 
back every time the user enters a specific category. 
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Scope 



The present document specifies how to create a broadcast carousel of objects for an audio information service. 
TopNews allows a service provider to deliver compressed audio, for instance MP3, via digital radio. Receivers may 
then extract information directly from this carousel and store it in the receiver in order to present the service. 

To simplify the delivery of additional text and image files TopNews is designed as a profile of the Broadcast Website 
user application (TS 101 498-1 [4]). BWS itself and TopNews are based on the MOT protocol (EN 301 234 [3]). 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

[1] ETSI EN 300 401: "Radio Broadcasting Systems; Digital Audio Broadcasting (DAB) to mobile, 

portable and fixed receivers". 

[2] ETSI TS 101 756: "Digital Audio Broadcasting (DAB); Registered Tables". 

[3] ETSI EN 301 234: "Digital Audio Broadcasting (DAB); Multimedia Object Transfer (MOT) 

protocol". 

[4] ETSI TS 101 498-1: "Digital Audio Broadcasting (DAB); Broadcast website; Part 1: User 

application specification". 

[5] ISO/IEC 1 1 172-3 (1993): "Information technology - Coding of moving pictures and associated 

audio for digital storage media at up to 1,5 Mbit/s - Part 3: Audio". 

[6] ISO/IEC 13818-3: "Information technology - Generic coding of moving picture and associated 

audio information - Part 3: Audio". 

[7] ISO/IEC 10646: "Information technology - Universal Multiple-Octet Coded Character Set (UCS)". 

[8] id3v2.4.0-structure: "ID3 tag version 2.4.0 - Main Structure". 

NOTE: See http://www.id3.Org/id3v2.4.0-structure.txt . 
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Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

BWS Broadcast Web Site 

DAB Digital Audio Broadcasting 

HTML Hyper Text Markup Language 

kbps Kbit / second 

MOT Multimedia Object Transfer 

MP2 MPEG 1 or 2, Audio Layer 2 

MP3 MPEG 1 or 2, Audio Layer 3 

PDA Personal Digital Assistant 

TN TopNews 



Syntax specification 



The specifications of syntax that appear in the present document are written using a form of pseudo-code that is similar 
to the procedural language C; this provides for easy specification of loops and conditional data structures. Within these 
specifications, the type of individual data fields is expressed using the mnemonics given in table 1 . 

Table 1 : Data type mnemonics for syntax specification 



Mnemonic 


Description 


Uimsbf 


Unsigned integer, most significant bit first 



TopNews basic profile specification 



The profile specified in the following clauses defines the profile for the MOT Broadcast Web Site user application 
corresponding to the Profileld value 0x02. 

5.1 Introduction 

TopNews uses the MOT protocol. It allows a service provider to deliver compressed audio files (e.g. MP3) via DAB. 
Since TopNews is based on the BWS application, all necessary provisions on the content creation and distribution side 
are already available. MOT TopNews is easy to implement on both the broadcast side as well as on the receiver side. 
TopNews itself is flexible and can be further enhanced in the future by defining extensions and additional profiles. 

TopNews has to handle a large number of short audio objects in many different categories (for example traffic 
messages) but also a small number of long audio objects. It is possible that the TopNews content itself is not 
characterised as single unit but as a collection of independent objects. Therefore the receiver should always be able to 
decode the TopNews data and start presenting objects as soon as they are received. Over time, the number of objects 
and categories increases until all objects have been received. From time to time, the number of categories and the 
number of objects within the categories may change dynamically. 

TopNews is embedded in the Broadcast Web Site user application as its own profile. This allows on the one hand easy 
integration of additional text and images to TopNews data in the future and on the other hand easy integration of 
TopNews objects in other BWS profiles. So TopNews can be combined with already existing visual HTML based 
profiles of BWS. 
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5.2 The TopNews MOT carousel 



The data for TopNews shall be carried as TopNews profile in the MOT BWS user application (TS 101 498-1 [4]). 

Being a profile of the BWS user application implies the use of the MOT directory mode. The MOT data carousel can be 
transported in PAD or in a packet mode channel. TopNews can be linked logically to an audio service or it can be a 
stand-alone TopNews data service. 

The following extensions and restrictions apply for this TopNews basic profile: 

• The directory entries of the MOT directory shall be sorted in ascending order of the ContentName parameter at 
the service provider side (this reduces the complexity for MOT directory comparison, see clause 5.4.1). 

• No transport level compression of the MOT directory is allowed (this reduces the complexity for MOT 
directory decoding). 

• The MOT directory shall remain unchanged for a minimum period of 2 minutes. 

NOTE: Due to reception errors, a receiver might be unable to get an error free reception of an MOT body before 
transmission of the next MOT body starts. Appropriate measures need to be taken to ensure that in case of 
reception errors the MOT body can be completed during the next repetition(s) of the MOT body. 

Within the MOT carousel, MOT parameters can be associated with individual objects by placing them in the MOT 
Header core and the MOT Header Extensions. MOT parameters referring to the complete set of objects are placed into 
the MOT directory extension. 

Only extensions or restrictions of the MOT standard (EN 301 234 [3]) or the BWS user application (TS 101 498-1 [4]) 
are specified within the present document. 

5.3 MOT parameters for individual objects 

MOT parameters that are to be applied to individual MOT objects are carried in the MOT header of each directory entry 
in the MOT directory. 

A summary of the use of MOT parameters for individual objects that apply to the BWS TopNews profile is given in 
table 2, and is specified in detail by the following clauses. 

NOTE 1 : Other parameters may be defined within the context of specific profile definition. Any parameters that are 
encountered that are not understood by a given receiver profile are ignored. 

If the MOT parameters ProfileSubset, ContentName and/or UniqueBodyVersion are used, then these parameter should 
be sorted in this order and placed at the beginning of the MOT parameter list of the MOT header to further reduce the 
complexity for MOT directory comparison. 

Table 2: Use of MOT parameters for individual objects 



Parameter 


Parameter Id 


Specified in 


Mandatory for 
service provider 


Mandatory for 
Receiver 


Occurrence 


ProfileSubset 


0x21 


MOT 


No 


No 


Single 


ContentName 


OxOC 


MOT and BWS 


Yes 


Yes 


Single 


UniqueBodyVersion 


0x0 D 


MOT 


Yes 


No 


Single 














ContentSorting 


0x2a 


TN 


Yes 


Yes 


Multiple 


ContentDescription 


0x28 


TN 


Yes 


No 


Single 


Headline 


0x29 


TN 


No 


No 


Single 


Duration 


0x2b 


TN 


No 


No 


Single 


PresentationThreshold 


0x2c 


TN 


No 


Yes 


Single 



NOTE 2: The parameter identifiers defined by the TopNews basic profile could also be used by other user 
applications for parameters with completely different meanings. 
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5.3.1 MOT Header Core settings 

The ContentType and -SubType shall be set according to the MOT specification (EN 301 524 [3]). 

EXAMPLE: For an MP2 audio object the 'ContentType' shall be set to '00 001 l bin ' (audio) and the 

'ContentSubType' to either '0 0000 0001 bin ' (MPEG I audio Layer II) or '0 0000 0100 bin ' (MPEG II 
audio Layer II). 

5.3.2 The ProfileSubset parameter 

This optional parameter indicates the MOT object(s) used by the profile. 

The ProfileSubset parameter is used as specified in the MOT specification (EN 301 524 [3]). 

5.3.3 The ContentName parameter 

This mandatory parameter uniquely identifies the MOT object within the MOT carousel and within TopNews. 

The ContentName parameter is used as specified in the MOT specification (EN 301 524 [3]) and in the BWS 
specification (TS 101 498-1 [4]). Additionally the following extensions and restrictions apply for TopNews: 

• The permitted file extensions are specified in clause 6. 

• The parameter ContentName should not be presented to the user for selection of a TopNews object. The 
receiver shall display the ContentDescription of the object or the appropriate ID3 tag. 

5.3.3.1 The ContentName parameter for interoperability 

If the service provider wants to permit TopNews receivers to store the received TopNews content on removable media 
such as a memory card and to use another non TopNews capable device, like a simple MP3 player to play back the 
TopNews content, then the service provider should use the scheme presented in this clause to define the ContentNames 
for the TopNews content. Nevertheless only an approximation to TopNews is possible. 

A receiver which supports this kind of interoperability (i.e. play back of TopNews data on non-TopNews devices) must 
store the TopNews objects with their ContentName parameters as full file names (path and file name) in the file system. 

All the additional extensions and restrictions described in this clause are optional. However, not fulfilling these 
extensions and restrictions will make it unlikely that TopNews content can be presented on non-TopNews devices. 

The parameter ContentName should not be presented to the user for selection of a TopNews object. However to allow 
interoperability with devices which can only present the directory and file name, the ContentName parameter should 
describe the content as far as possible, so that a simple media player can make use of the content and category identifier 
of the ContentName while playing the objects (table 3). 

It is highly recommended that the ContentName is a valid file- and directory name for all file systems used for 
TopNews receivers and to use short names for every part (e.g. 8 characters). 

To permit interoperability, the character set for the ContentName of TopNews objects shall be ISO Latin Alphabet No 1 
(see TS 101 756 [2]). The permitted characters are restricted to a subset of this character set as follows: the lowercase 
Latin letters, the digits, the hyphen, the forward slash and the underscore ("a".."z", "0".."9", "-", "/", "_"). 

The ContentName should consist of three parts: The path consisting of multiple (1-x) path components 
(1 to 8 characters in length) separated by a slash, the category identifier / directory name (1 to 8 characters) and the 
content identifier / file name (1 to 8 characters) followed by a "." and the file name extension (1 to 3 characters). Every 
part is separated with a slash character. The permitted file extensions are specified in clause 6. 
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Table 3: Syntax of the ContentName parameter data field for interoperability 



Syntax 


Size (bits) 


Type 


ContentName_parameter_data_f ield ( ) { 






For (i=0; i<M; i++) { 






Path Component 


n x 8; n <= 8 


uimsbf 


/ 


8 


uimsbf 


} 






Category Identifier 


m x 8; m <= 8 


uimsbf 


/ 


8 


uimsbf 


Content Identifier 


p x 8; p <= 8 


uimsbf 




8 


uimsbf 


File Extension 


r x 8; r<=3 


uimsbf 


} 







NOTE 1: It is recommended to use a ContentName having a content identifier "index" and the appropriate file 
extension for all service and category index objects. This is similar to commonly used file names for 
index pages on Internet web servers. 

NOTE 2: If a message object belongs to more than one category, the ContentName parameter should use the first 
category as the name source. 

Further support for interoperability devices can be found in clauses 6.2.1 and 6.2.2. 

5.3.4 The UniqueBodyVersion parameter 

This mandatory parameter is used for version control and for the independent update of the header information of the 
MOT body. 

The UniqueBodyVersion parameter is used as specified in the MOT specification (EN 301 524 [3]). Additionally the 
following extensions and restrictions apply for TopNews: 

• It is optional but recommended for service provider and receiver to support the MOT parameters Expiration in 
the header information and DefaultExpiration in the directory extension of the MOT directory as specified in 
the MOT specification (EN 301 524 [3]). 

NOTE: The TopNews application sometimes needs to change the header information but not the MOT body of an 
MOT object (for example, a change to the sorting of message objects, see clause 5.3.5). With the 
signalling of the same UniqueBodyVersion parameter value and a changed Transportld the header 
information can be changed without the need to delete and to reassemble an already decoded MOT body 
again. 

5.3.5 The ContentSorting parameter 

The use of this TopNews parameter for each MOT object is mandatory. The ContentSorting parameter identifies the 
different object types (service index, category index and message object), gives information about the sorting of the 
content within the TopNews profile and allows message objects to be placed in more than one category. 

The ContentSorting parameter consists of two unsigned integer numbers from to 65535. These are the message 
number within a category and the category number within the TopNews profile. 

Table 4: Syntax of the ContentSorting parameter data field 



Syntax 


Size (bits) 


Type 


ContentSorting_parameter_data_f ield ( ) { 






message number 


16 


uimsbf 


category number 


16 


uimsbf 


} 
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5.3.5.1 



TopNews Object type 



To distinguish between the three different object types (i.e. service index, category index and message object), both 
numbers are set in a special way. With these settings it is easy to identify the object type on the receiver side. For the 
usage of the object types please see clause 6.3. 

If an MOT object is the service index of the complete TopNews profile data, the message number and the category 
number shall be set to 0. The category number within every TopNews profile data is reserved for its service index. 
Only one service index is allowed in each TopNews profile data. It is mandatory to send the service index. 

If an MOT object is the category index, the message number shall be set to and the category number shall be set to a 
number greater than 0. The message number within every category is reserved for its category index. Only one 
category index is allowed for each category (see clause 5.3.5.2). It is mandatory to send a category index for each 
category in use. 

If an MOT object is a message object, the message number and the category number shall be set to a number greater 0. 
All MOT objects with the same category number belong to the same category. It is allowed to signal multiple messages 
for every category even with the same message number (see clause 5.3.5.3). 

Table 5: Summary of message number and category number allocation 





message number 


category number 


Service Index 








Category Index 





>0 


Message Object 


>0 


>0 



5.3.5.2 



Presentation order of categories 



The order in which the categories are presented to the user shall be derived from the category number of the 
ContentSorting parameter. The category with the lowest category number shall be presented first followed by the 
category with the next higher category number and so on. So the categories are ordered in ascending order of the 
category number. 

NOTE: If the presentation order of the categories is changed, then an update of the affected header information of 
the MOT objects in the MOT directory has to be performed. The use of the UniqueBodyVersion 
parameter supports this (see clause 5.3.4). 



5.3.5.3 



Presentation order of message objects 



The order in which the messages within a category are presented to the user shall be derived from the message number 
of the ContentSorting parameter. The message with the lowest message number shall be presented first followed by the 
message with the next higher message number and so on. So the messages are ordered in ascending order of the 
message number. The sorting order of message objects having the same message number is undefined. 

NOTE: If the presentation order of the objects is changed, then an update of the affected header information of 
the MOT objects in the MOT directory has to be performed. The use of the UniqueBodyVersion 
parameter supports this (see clause 5.3.4). 



5.3.5.4 



Message objects in multiple categories 



A message object can appear in more than one category. To achieve this the header information of the MOT object can 
have more than one ContentSorting parameter. So the message object belongs to all the categories the different category 
numbers specify. 

While it is quite easy to ensure that a message is put into multiple categories, it is not so easy to ensure that the message 
is removed from all categories if it is DELETED or UPDATED. The (implicit) delete command does not give the 
category names the message formerly belonged to, and an update using the same ContentName might be totally 
unrelated to the old message (it might have different categories from the original). Receivers shall be designed to handle 
this situation. 

NOTE 1: There are no problems with message objects in multiple categories because all ContentNames are unique. 
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NOTE 2: If the membership of different categories for an object is changed, then an update of the affected header 
information of the MOT object in the MOT directory has to be performed. The use of the 
UniqueBodyVersion parameter supports this (see clause 5.3.4). 

5.3.6 The ContentDescription parameter 

The use of this TopNews parameter for each MOT object is mandatory. This MOT parameter contains the full 
description of the object with the maximum length of 256 characters or a maximum of 1 024 bytes. The character set 
used shall be ISO/IEC 10646 [7] (UTF-8 encoding). The ContentDescription may be presented to the user for selection 
and so it should describe the service, the category or the message itself. 

Table 6: Syntax of the ContentDescription parameter data field 



Syntax 


Size (bits) 


Type 


ContentDescription_parameter_data_f ield () { 






Content description 


n x 8; n<= 1024 


uimsbf 


} 







If an encoded audio file uses ID3 tags to describe the object, the ID3 tag shall use the same description (see 
clause 6.2.1). 

5.3.7 The Headline parameter 

The use of this TopNews parameter for each MOT object is optional. The Headline parameter is an unsigned integer 
number of two bytes giving a time interval as a multiple of tenths of seconds (100 ms). This number indicates the 
position in the audio object where the headline of the message ends and the content of the message starts. This allows a 
receiver to play only the headline of a message object. For playback purposes, the headline of the message is a complete 
set of audio frames whose playing time is equal to or greater than the time indicated by the Headline parameter. 

Table 7: Syntax of the Headline parameter data field 



Syntax 


Size (bits) 


Type 


Headline_parameter_data_f ield ( ) { 






Position 


16 


uimsbf 


} 







5.3.8 The Duration parameter 

The use of this TopNews parameter for each MOT object is optional. The Duration parameter is an unsigned integer 
number from to 65535. This number gives the duration of the audio object in seconds. If necessary the duration of the 
audio object shall be rounded to the next higher integer value. 

Table 8: Syntax of the Duration parameter data field 



Syntax 


Size (bits) 


Type 


Duration_parameter_data_f ield () { 






Time 


16 


uimsbf 


} 







NOTE: The Duration parameter is only intended for display purposes to the user. For the exact duration the audio 
object itself must be checked. 
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5.3.9 The PresentationThreshold parameter, individual 

This TopNews parameter for a category index is optional for the service provider and mandatory for the receiver. The 
PresentationThreshold parameter indicates the necessary minimum number of available objects in a category on the 
receiver to access this category. The PresentationThreshold is an unsigned integer number from to 65 535. This 
number represents the necessary minimum number of objects in a category. The number of objects includes the 
category index and all message objects of this category. The value Oxffff, indicates that every object in a category must 
be available to present the category. 

Table 9: Syntax of the PresentationThreshold parameter data field 



Syntax 


Size (bits) 


Type 


PresentationThreshold_parameter_data_f ield ( ) { 






MinimumNumber 


16 


uimsbf 









The PresentationThreshold parameter shall be used only for the category index. If not set for a specific category index 
the PresentationThreshold parameter in the directory extension of the MOT directory shall be used. If a 
PresentationThreshold parameter in the directory extension of the MOT directory is signalled, then the individual 
PresentationThreshold for the category index supersedes the directory extension value. If the PresentationThreshold 
parameter is not used at all (or is invalid) the default value has to be assumed and this value corresponds to 
necessary objects. 

NOTE 1 : With a value of the presentation of a TopNews category can start with the first decoded object that is 
available. With a value of Oxffff every object of the category must be decoded before the presentation of 
the category can start. This maximum requirement will considerably delay the presentation start. 

NOTE 2: If the objects of the category change as indicated by the MOT directory, the presentation must be stopped 
if the necessary number of objects is not available on the receiver anymore. The user may have to wait a 
long time while using this TopNews data. 

5.4 MOT parameters for the entire carousel 

MOT parameters that are to be applied to the entire carousel are placed in the DirectoryExtension field of the MOT 
directory. 

A summary of the use of MOT parameters for the entire carousel that apply for the B WS TopNews profile is given in 
table 10, and is specified in detail by the following clauses. 

Table 10: Use of MOT parameters for the entire carousel 



Parameter 


Parameter Id 


Specified in 


Mandatory for 
service provider 


Mandatory for 
Receiver 


Occurrence 


SortedHeaderlnformation 


0x00 


MOT 


Yes 


No 


Single 


SpecialEntry 


0x2d 


TN 


No 


No 


Single 


PresentationThreshold 


0x2c 


TN 


No 


Yes 


Single 



NOTE 1 : Other parameters may be defined within the context of specific profile definition. Any parameters that are 
encountered that are not understood by a given receiver profile will be ignored. 

NOTE 2: The parameter identifiers defined by the TopNews basic profile could also be used by other user 
applications for parameters with completely different meanings. 

5.4.1 The SortedHeaderlnformation parameter 

This mandatory parameter is used to signal that the directory entries within the MOT directory are sorted in ascending 
order of the ContentName parameter. 

The SortedHeaderlnformation parameter is used as specified in the MOT specification (EN 301 524 [3]). 
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5.4.2 The SpecialEntry parameter 



The use of this TopNews parameter is optional. The SpecialEntry parameter gives a link to a special object of the 
TopNews profile that should be the first object played when the service is started in a special way. 

The parameter coding is identical to the ContentName parameter (see clause 5.3.3). 

Table 11 : Syntax of the SpecialEntry parameter data field 



Syntax 


Size (bits) 


Type 


SpecialEntry_parameter„data_f ield ( ) { 






ContentName 


n x 8 


uimsbf 


} 







When starting TopNews normally the service index will be played first and then the listener can select categories and 
messages he is interested in. If the service provider wants to promote a TopNews message or category that should be 
played when a special button on the TopNews receiver is pressed then the SpecialEntry parameter should be set. If the 
parameter is not set by default the service index corresponding to a ContentSorting value of (0, 0) shall be the special 
object. So this parameter supersedes all other presentation priority strategies. The category and message order remains 
unchanged. 

To enable this feature, a TopNews receiver needs two different ways to enter the TopNews application: 

• the "normal" way starting at the service index; 

• the "promoted message" way that starts at the special TopNews message or category and afterwards continues 
at this position with the normal presentation strategy. 

5.4.3 The PresentationThreshold parameter, entire 

This TopNews parameter is optional for the service provider and mandatory for the receiver. The PresentationThreshold 
parameter indicates the necessary minimum number of available objects in a category on the receiver to access this 
category. The PresentationThreshold is an unsigned integer number from to 65 535. This number represents the 
necessary minimum number of objects in a category. The number of objects includes the category index and all 
message objects of this category. The value Oxffff, indicates that every object in a category must be available to present 
the category. 

Table 12: Syntax of the PresentationThreshold parameter data field 



Syntax 


Size (bits) 


Type 


PresentationThreshold __parameter_data_f ield () { 






MinimumNumber 


16 


uimsbf 









The PresentationThreshold parameter in the directory extension of the MOT directory shall be used for all categories. If 
an individual PresentationThreshold parameter is set for a specific category in the MOT header of the category index of 
this category, then this individual parameter supersedes the directory extension value for this category. If the 
PresentationThreshold parameter is not used at all (or is invalid) the default value has to be assumed and this value 
corresponds to necessary objects. 

NOTE 1 : With a value of the presentation of a TopNews category can start with the first decoded object that is 
available. With a value of Oxffff every object of the category must be decoded before the presentation of 
the category can start. This maximum requirement will considerably delay the presentation start. 

NOTE 2: If the objects of the category change as indicated by the MOT directory, the presentation must be stopped 
if the necessary number of objects is not available on the receiver anymore. The user may have to wait a 
long time while using this TopNews data. 
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5.5 Other MOT parameters 



No transport level compression of the TopNews objects of this profile is allowed. For this reason the BWS parameter 
CompressionType shall not be used for MOT objects within this profile. 

The BWS user application is based on HTML. Because a Directorylndex parameter for this profile could only present 
an audio object, this parameter is not used for this profile. 

All other MOT parameters necessary for BWS (MimeType, AdditionalHeader, CAInfo, etc.) are used as specified in the 
BWS (TS 101 498-1 [4]) and MOT (EN 301 524 [3]) specifications. 

It is recommended for service provider and receiver to support MOT persistent caching (MOT parameters Expiration, 
DefaultExpiration, PermitOutdatedVersions, DefaultPermitOutdatedVersions, etc.) as specified in the MOT 
specification (EN 301 524 [3]). 

NOTE 1 : If Expiration is used, the receiver will lose the ability to present the complete TopNews structure if the 
category index and/or the service index expires. 

NOTE 2: If Expiration is used the user will have access to a decreasing number of MOT objects with time because 
MOT objects will expire during use. An indication to the user for the reason would be beneficial. 

NOTE 3: If PermitOutdatedVersions is used the service provider has to keep in mind that the MOT specification 

(EN 301 524 [3]) requires that all changes of the header information, e.g. a new sorting, cannot be applied 
by the receiver until the new MOT body is decoded. Changes of the directory extension of the MOT 
directory can be applied immediately. If this is not acceptable the service provider has first to change the 
header information, hope that the receiver receives this intermediate MOT directory and send with the 
next MOT directory the new MOT body. 



5.6 Application Signalling 



The use of TopNews within a DAB data channel shall be indicated by use of FIG 0/13 with the UserApplicationType 
value of the MOT BWS application (see TS 101 756 [2]) and the UserApplicationDataField with the TopNews 
Profileld. 

The Profileld for this TopNews Basic Profile Specification has the value 0x02. 



6 TopNews Application Structure 

6.1 Supported content types 

Integrated TopNews receivers are only required to support the content types specified below. 

All other content types may be decoded and stored by a TopNews receiver to enable use of the TopNews data on a non- 
specific device (e.g. PDA), see clause 6.2.2. 

6.1.1 Content type audio 

The supported audio compression formats are described in detail in clauses 6.1.1.1 and 6.1.1.2. 

Receivers shall insert a pause between two consecutive played audio objects by default. Therefore audio objects do not 
require a lead in and out. 

6.1.1.1 MP2 parameters 

The audio objects shall be encoded in MPEG 1 (ISO/IEC 1 1 172-3 [5]) or MPEG2 (ISO/IEC 13818-3 [6]) Layer 2 
format commonly known as MP2 format. 

There are no restrictions to the data rate, sampling frequencies or submodes. 
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The file extension in the MOT parameter ContentName shall be "mp2". 



6.1.1.2 



MP3 parameters 



The audio objects shall be encoded in MPEG 1 (ISO/IEC 1 1 172-3 [5]) or MPEG2 (ISO/IEC 13818-3 [6]) Layer 3 
format commonly known as MP3 format. 

There are no restrictions to the data rate, sampling frequencies or submodes. 

The file extension in the MOT parameter ContentName shall be "mp3". 

6.2 Meta data for enhanced interoperability 

To support the interoperability of TopNews with players which are not TopNews equipped, e.g. a simple media player, 
additional parameters to describe the objects and the service can be broadcast. This clause describes optional additions. 

6.2.1 ID3tags 

The information of the ID3 tag version 1 and 2 (id3v2.4.0-structure [8]) can give a more detailed description of MP2 
and MP3 audio objects. The ID3vl tag ARTIST shall correspond to the ContentDescription of the service index, the 
ALBUM tag to the ContentDescription of the category index and the TITLE tag to the ContentDescription of the 
message object. The TRACK shall correspond to the message number of the ContentSorting parameter. For ID3v2 only, 
the TPOS shall correspond to the category number of the ContentSorting parameter. 

For a service index object, all three ID3vl tags shall be identical. 

For a category index object, the ID3vl ALBUM and ARTIST tags shall be identical. For ID3v2 the respective tags shall 
be used. The ID3 specification provides further information (id3v2.4.0-structure [8]). 

NOTE: If a message object belongs to more than one category the ID3 tags should be set for the first category. 

Table 13: ID3 tag usage 



Object type 


ID3v1 tag 


ID3v2 tag 


MOT parameter 


Example 


message object 


ARTIST 


TPE1 


ContentDescription from service index 


Rockland SA 




ALBUM 


TALB 


ContentDescription from category index 


World News 




TITLE 


TIT2 


ContentDescription from message object 


Discovery of a new Species 




TRACK 


TRCK 


ContentSorting, message number 


1 




- 


TPOS 


ContentSorting, category number 


1 


category index 


ARTIST 


TPE1 


ContentDescription from service index 


Rockland SA 




ALBUM 


TALB 


ContentDescription from category index 


World News 




TITLE 


TIT2 


ContentDescription from category index 


World News 




TRACK 


TRCK 


ContentSorting, message number 







- 


TPOS 


ContentSorting, category number 


1 


service index 


ARTIST 


TPE1 


ContentDescription from service index 


Rockland SA 




ALBUM 


TALB 


ContentDescription from service index 


Rockland SA 




TITLE 


TIT2 


ContentDescription from service index 


Rockland SA 




TRACK 


TRCK 


ContentSorting, message number 







- 


TPOS 


ContentSorting, category number 






6.2.2 Playlists / application meta data 

Application meta data for the TopNews service may be generated as additional MOT objects. This enables TopNews to 
be presented from the object cache of non-TopNews capable receiver devices like PDAs or portable audio players. 

The application meta data is not specified - it is assumed that suitable application decoders will develop within IT 
communities and be made available to device users. 

EXAMPLE 1: An HTML page could be generated which has links to the individual TopNews audio objects. By 
clicking on the links the files are played with the default media player of the system. 
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EXAMPLE 2: An object "tna_pc.htm" could be broadcast for a PC based application decoder using a website. 

EXAMPLE 3: An object "tna_mp.asx" could be broadcast for Windows media player as an ASX playlist. 

EXAMPLE 4: An object "tna_wamp.m3u" could be broadcast for Winamp media player as an M3U playlist. 

EXAMPLE 5: An object "tna_pc.js" could be broadcast for PCs as Java script. 

EXAMPLE 6: An object "tna_xml.xml" could be broadcast as generic XML. 

The description of this application meta data is provided as additional MOT objects within the MOT data carousel. 
These additional MOT objects shall be stored in the file system of the moveable storage media. It is mandatory for any 
receiver to store these files if they are used for interoperability purposes. 

These MOT objects belong to the TopNews profile as identified by the MOT ProfileSubset parameter with the 
TopNews Profileld. However, they have a content type different to those specified in clause 6.1 and therefore they have 
no TopNews specific MOT parameters (ContentSorting, ContentDescription, Headline, Duration, 
PresentationThreshold). These TopNews specific parameters shall not be used with these objects. 

The objects are transported as specified in the BWS application (TS 101 498-1 [4]) using the appropriate ContentType, 
ContentSubType according to the MOT specification (EN 301 524 [3]). 

6.3 Category structure and signalling 

All TopNews objects are categorised. The signalling of the categories and the full description of the category as well as 
the description of the transmitted objects itself is done using the MOT parameters ContentSorting and 
ContentDescription. 

There are no predefined categories. All categories are created and named with the parameter ContentSorting and 
ContentDescription. This is up to the service provider. 

The receiver has to handle new categories and new message objects. The number of categories and message objects 
may change dynamically. The change rate shall be longer than 2 minutes because of the limitations of the MOT 
directory transport mode. 

NOTE 1: The transmission of the objects may be interleaved over the categories to enable receivers to quickly 
establish the structure of the TopNews categories. 

NOTE 2: Newly received unsorted message objects in the selected category may be played first. 



News 



Sport 



index 



Newsl 



News2 



index 



Sport 1 



Sport2 



Figure 1 : Logical structure of TopNews 
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/news/index. 


mp3 


/news/newsl 


mp3 


/news/news 2 


mp3 


/sport/index. 


mp3 


/sport/sportl 


mp3 


/sport/sport2 


mp3 



Figure 2: Possible directory structure containing the above service 

One audio object of each service, the service index, is treated as an audio description of this service and should be 
played when entering the service. One audio object of each category, the category index, is treated as an audio 
description of this category and should be played when entering this category and skipped if the user browses inside this 
category. These index objects are identified with the MOT parameter ContentSorting. The category order and the order 
of the message objects in the categories are defined with the ContentSorting parameter. 

The textual description of an audio object should be presented to the user while playing this audio object. This 
description is signalled with the MOT parameter ContentDescription. 

If a TopNews object has not yet been decoded when the user requests it, an audio place holder (e.g. a "beep") shall be 
provided to the user to indicate that the object is currently unavailable. The receiver may combine multiple audio place 
holders which appear in a row to a single place holder. The ContentDescription for each object should always be 
presented. 

The TopNews service of the currently tuned audio service has the highest priority in a possible list of different 
TopNews services. TopNews services linked to other audio services should not be presented. The user has first to 
switch to these audio services. TopNews data services (those not linked to an audio service) may be accessed from a 
list. 



6.4 Object life cycle 



The life cycle of an object and especially the possibilities to modify them are described in detail in the BWS 
(TS 101 498-1 [4]) and MOT (EN 301 524 [3]) specifications. This includes the creation, update and deletion 
possibilities. Only completely decoded objects shall be presented to the user. 



6.5 Navigation controls 



A TopNews user application decoder shall provide the "change category" control and the "change message" control to 
allow manual playback. 

Additionally, one automatic playback function should be implemented to first play the service index and then all the 
categories in the correct order, one after the other. Within a category, first the category index and then the message 
objects in the correct order are played. 

For the special entry functionality described in clause 5.4.2, an additional "special entry" control is necessary. 

6.5.1 Change category 

The "change category" control allows the user to select the next category from the available list of categories. At its 
simplest, this may be implemented as a single control that cycles through all the available categories in the order in 
which they are sorted. The played category index and its ContentDescription shall be used to give user feedback about 
the current category. 
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6.5.2 Change message 



The "change message" control allows the user to select the next object from the available list of messages in a category. 
At its simplest, this may be implemented as a single control that cycles through all the available messages in one 
category in the order in which they are sorted. It is assumed that an appropriate mechanism will be used to give user 
feedback about the current message. 



6.6 Quality of Service parameters 



Quality of service parameters are relevant when the content for a service can be successfully interpreted by the receiver 
software without error, but where the resulting presentation is unacceptably degraded if the receiver cannot meet the 
requirements. 

Clauses 6.6.1 to 6.6.6 describe some of the quality of service parameters that should be considered. 

6.6.1 Transport channel limitations 

The main target device for the TopNews profile is an embedded receiver with limited capabilities. Therefore limitations 
are placed on the transportation of objects to reduce the necessary memory and processor requirements of the decoder. 

No MOT object of this profile shall be interleaved with another MOT object of this profile. MOT objects shall be 
broadcast one after the other. The only exception is the MOT Directory itself, which can be interleaved with the MOT 
objects of this profile. 

For MOT carousels containing objects for the TopNews profile, the data rate, whether transported in packet mode or 
PAD, is limited to a maximum of 64 kbps. For packet mode transport, the overall size of a subchannel including the 
TopNews profile is limited to a maximum of 128 kbps. 

6.6.2 Maximum object size 

The maximum size of any object in the carousel is 512 kByte. 

NOTE: 1 minute of audio encoded at 32 kbps equals 240 kByte. 

6.6.3 Minimum receiver cache size 

The MOT carousel can be used to deliver a set of files in a broadcast Digital Radio channel and can operate entirely 
without cache memory, if desired. However, the effect of cache memory is to improve the performance of the carousel 
with respect to carousel access time, and so directly affects the perceived quality of the service (cache memory cannot 
improve service acquisition time, however). 

In order to guarantee a certain level of service performance, the minimum amount of receiver cache memory shall be 
8 MByte. The service provider must be aware that if this data rate is exceeded, the memory management behaviour of 
the receiver is unforeseen. 

NOTE: 30 minutes of audio encoded at 32 kbps equals 7,6 MByte. 

6.6.4 Minimum receiver audio characteristics 

An integrated receiver can have limited audio playback capabilities. In order to guarantee a certain level of service 
performance, the minimum playback capability shall be MP2 and MP3. 

6.6.5 Minimum receiver display characteristics 

There are no minimum receiver display characteristics. The service can be operated without any visual feedback using 
the service and category index objects. However even a limited display can improve the service considerably. 
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6.6.6 Maximum carousel period 



No limitation of the carousel period is necessary. Nevertheless if the carousel period is too long the receiver may have 
problems decoding all TopNews objects. 
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